A Dynamic Approach to Estimate Receiving Bandwidth for WebRTC

Web Real-Time Communication (WebRTC), drafted by the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF), enables direct browser-to-browser real-time communication. As its congestion control mechanism, WebRTC uses the Google Congestion Control (GCC) algorithm. But using GCC will limit WebRTC’s performance in cases of overusing due to using a fixed decreasing factor, known as alpha (α). In this paper, we propose a dynamic alpha model to reduce the receiving bandwidth estimate during overuse as indicated by the overuse detector. Using our proposed model, the receiver can more efficiently estimate its receiving rate in case of overuse. We implemented our model over both unconstrained and constrained networks. Experimental results show noticeable improvements in terms of higher incoming rate, lower Round-Trip Time, and lower packet loss compared to the fixed alpha model. Keywords: WebRTC, Bandwidth Estimation, Congestion Control, Video Conferencing, Dynamic alpha. INTRODUCTION Popularity of mobile technologies such as smartphones and tablets has encouraged competition amongst the video conferencing system researchers and developers to enhance the Real-Time Communication (RTC) technology as well as to implement various applications based on RTC. Accessibility and mobility of multimedia and video conferencing applications has also motivated the creation of browser-to-browser video conferencing technologies that can compete with the current standalone video conferencing applications [1],[2]. In 2012, Web Real-Time Communication (WebRTC) was proposed with the aim to implement RTC into web browsers, enabling audiovisual calls between two or more end users with no need to install third party plugins or specific applications. Real-Time Communication on the Web (RTCWeb) is an open source project of the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) team that aims to standardize protocols and infrastructures for WebRTC [3]. Web developers can add WebRTC features to their browsers using standard Hyper Text Markup Language (HTML5) with simple Javascript APIs [4]. Therefore, it allows any web browser running on any operating system and any device to connect seamlessly with any other web browser running on any operating system and any device via the internet and communicate in real-time, as long as both web browsers support WebRTC. WebRTC is open source, and it is currently implemented in three browsers: Google Chrome, Firefox, and Opera [3]. Like any other RTC application, WebRTC has to deal with the quality from two different perspectives – user and network. From the user’s perspective, services such audio-video streams have to be provided with less packet loss and delays, along with a high incoming rate and quality. From the network perspective, WebRTC has to have a mechanism that can deal with bottleneck problems and congestion to produce acceptable performance during a video session. Therefore, the IETF and W3C working groups proposed a congestion control mechanism, called Google Congestion Control (GCC) algorithm, for WebRTC to satisfy the quality requirements for realtime applications [5]. GCC has two main controllers: Receiver-side controller and Sender-side controller, as shown in Figure 1 [9]-[11]. The Receiver-side controller computes the next expected receiving rate Ar. It is composed of five main components: Arrival-time filter (estimates the queuing time variation T), Remote rate region (computes the threshold γ), Overuse detector (produces appropriate signal, overuse/underuse/normal, based on T and γ), Remote rate controller (estimates the next expected receiving rate Ar), and Receiver Estimated Max Bitrate (REMB) message processing unit (notifies sender with the next expected receiving rate). The Sender-side controller consists of two main components: TCP-Friendly Rate Control (TFRC) bandwidth estimation, and Sending Rate Controller. According to [11], sender-side controller is a loss-based congestion control algorithm which computes the target sending bitrate As. When congestion occurs, users experience packet losses or delays in picture or sound. In such a scenario, to decrease bandwidth usage and counter congestion, GCC’s receiver-side controller uses an overuse detector (which takes into account the queuing delay), and when the detector indicates overuse, GCC reduces the current incoming rate by a fixed factor denoted as alpha (α). As per [11], alpha is a decreasing factor that is typically chosen to be within the interval of [0.80, 0.95]. The receiver-side controller multiplies α by the current incoming rate to estimate the new receiving rate. But, this alpha is a fixed amount and does not take into account the amount of queuing delay. Therefore, regardless of how much overuse has occurred, the receiver-side has to decrease its rate by the fixed alpha. It is intuitive that this behavior is not efficient. One would expect a faster decrease of the incoming rate for more severe congestion, and a slower decrease for less severe congestion. In other words, the amount of decrease in incoming rate should be proportional to how bad the congestion is. But GCC currently does not take this proportion into account. This behavior eventually reflects negatively on WebRTC’s performance, resulting in a video session with a less than optimal video quality. In order to address this issue, we propose a dynamic rate adaption model, called dynamic alpha model, which takes the amount of network delay into consideration, and calculates the incoming rate reduction amount proportionally. We implemented this model in the WebRTC reference code [3] and evaluated it in both constrained (in terms of bandwidth capacity, packet loss rate, and delay) and unconstrained networks. Analysis of our experimental results shows that our dynamic alpha model will improve WebRTC’s performance when congestion occurs. Figure 1. GCC Receiver-side and Sender-side components The rest of this paper is organized as follows: we continue by describing in more details the inner workings of GCC, and then present our proposed model for dynamic alpha. We then describe our experimental setup, performance results, and their analysis, before concluding the paper. RELATED WORK In this section we explain the inner workings of GCC. But before that, and since the sender side in the GCC algorithm uses TCP-Friendly Rate Control (TFRC) to estimate the sending rate, we start with a description of the TFRC algorithm. TCP-Friendly Rate Control According to [21], RFC 5348 defines the TCP-friendly rate control as “TFRC is a congestion control mechanism designed for unicast flows operating in the Internet environment and competing with TCP traffic.” In other words, TFRC is a congestion control algorithm that provides a smooth transmission rate for real-time applications [8]. TFRC is designed to give the best performance for applications that use a fixed segment size and vary their sending rates in response to congestion [21]. However, for applications that do not use a fixed segment size, such as video applications, the TFRC perhaps gives less performance because these applications vary their sending rates according to the needs of the application. The Google Congestion Control senderside implements TFRC to estimate the sending rate based on Eq. 2. Later, we will cover how the sender side adjusts its sending rate based on the TFRC rate, and more details are presented in subsequent sections. TFRC calculates its transmission rate, according to the TCP throughput equation shown below [20]: X = $ % &'( ) *(,_%./(0 )'( 1 )3(4*053 &))) (1) In the above equation, X is the sending rate in byte/second, S is packet size in bytes, R is Round trip time in second, p is loss event rate between 0 and 1, t_RTO is the TCP retransmission timeout values in a second, and b is the number of packets acknowledged by a single TCP. The receiver uses timestamps and Round-Trip Time (RTT) to determine if losses belong to the same loss event or not. The TCP throughput equation takes the RTT to calculate the TFRC rate. The sender can adjust its sending rate, according to the TFRC rate [8]. According to [19], RFC 3448 is suited for many multimedia streaming applications. However, it is also used for the continuous flow of data [8]. The development of TFRC is still ongoing in the IETF group. Google Congestion Control algorithm In [12], authors presented a performance analysis of receiver-side real-time congestion control for WebRTC. According to [6], congestion occurs when resource demands exceed the capacity. From the network perspective, if we have two or more sources and each source increases its sending rate beyond the link capacity, then after a while the network will get congested. From the user perspective, congestion contributes to decreased quality, in the form of delay and/or packet loss. In order to allow the user to use the Internet as efficiently as possible, many congestion control mechanisms have been proposed [6]. As mentioned earlier, WebRTC uses the Google Congestion Control (GCC) Algorithm [5] for congestion control. GCC runs over the User Datagram Protocol (UDP) where the audio/video frames are encapsulated in Real Time Protocol (RTP) packets. The congestion control is applied only to the video streams since the audio streams bitrate are considered negligible. The GCC algorithm follows a rate-based congestion avoidance approach, where the sender is monitoring the packet loss and calculates the sending rate based on the feedback received from the receiver-side. The receiver-side informs the sender of the next expected receiving rate to prevent the sender from exceeding this rate. Sender-side then estimates the sending rate based on the feedback from the receiver side and applying the TFRC. As per [7], GCC sender-side implements TFRC to estimate the sending rate based on Eq. 1. The feedback from the receiver arrives in the form of Real-time Transport Control Protocol (RTCP) reports, which carry the packet loss rate (p) and Round-Trip Time (RTT). Also, the Receiver Estimated Maximum Bit (REMB) messages contain the maximum rate (Ar) that is expected to be handled by the receiver side. Therefore, the new sending rate must be less than the receiver’s rate estimation and larger than the TFRC. As in [9], the sender side uses the packet loss rate to estimate the sending rate (As), which is given by Eq. 2: As i = max{S i , As i − 1 1 − 0.5p } p ˃ 0.10 As i − 1 0.02 < p < 0.10 1.05 As i − 1 + 1kbps p < 0.02 (2) In Eq. 2, S(i) is the TCP throughput at time i that is used by TFRC, and p is the packet loss rate. The relationship between the packet loss rate and the estimation of the sending rate in Eq. 2 can be summarized as follows: 1) If p is larger than 10%, then the sending rate is decreased. 2) If p is less than 2%, then the sending rate is increased. 3) If p is between 2% and 10%, then the sender maintains the previous sending rate. In WebRTC, the receiver-side monitors both the video stream and changes in frame delay. According to [9], the receiver side utilizes an overuse detector and estimates the receiving rate based on Eq. 3. In this equation, Ar(i-1) is the previous receiving rate estimate, η is the receiving rate increase factor, R(i) is the current incoming rate, and α is the incoming rate decrease factor. α is a fixed value (normally chosen between 0.80 and 0.95) while the receiving rate estimate is constrained by the following condition [11]: Ar(i) < 1.5 × R(i) Ar i = ηAr i − 1 Increase Ar i − 1 Hold α R i Decrease (3) The overuse detector monitors the changes in the frame delay and the state of the bottleneck to produce one of the following three signals: Overuse, Underuse, or Normal. Algorithm 1 is derived from the reference codes available at [3], which is used to detect overuse. We can interpret the stream flow between receiver and sender from Figure 1. The media stream flow is sent by the sender to the receiver in RTP packets while the arrival-time filter computes the queuing delay variation, T. The remote rate region sets the threshold based on Algorithm 2. There are three region statuses that are set, based on whether we are far from congestion (MaxUnknown), close to congestion (NearMax), or congested (AboveMax). According to [11], the default threshold value used by the Chrome browser is 25/60 ms, but when we are close to congestion, the threshold is halved. Then, the over-use detector receives the queuing delay variation T from the arrival-time filter and the threshold from the remote control region to produce the appropriate signal. Based on the over-use detector signal, the remote rate controller estimates the receiving rate based on Eq. 3, and sends it to the sender via REMB messages with the packet loss rate value. On the sender-side, the sender receives the packet loss rate and the receiving rate estimate. Sender-side calculates the sending rate according to Eq. 1, and compares this rate with the TFRC throughput before setting the sending rate for the next stream segment. Algorithm-1: Overuse detector pseudo code 1 //Overuse Detector 
 2 IF number of deltas < 2 THEN 3 Overuse detector state = Normal 
 4 /*compute T, which is the offset estimate multiply of number of deltas*/ 
 5 T = min (number of deltas, 60) * offset 
 6 //compare T with threshold (γ) 
 7 IF T ˃ γ 
 8 // Initialize the timer of time of overusing (the time spent in overusing period) 
 9 IF time of overusing = -1 THEN 10 time of overusing = ts _deltas/2 
 11 ELSE 12 time of overusing = time of overusing + ts _deltas 
 13 // increase Overusing counter by 1 
 14 Overuse counter = +1 
 15 END IF 16 /* check if the time of overusing counter reaches Overusing time threshold 
 17 and check Overuse counter too */ 
 18 IF time of overusing ˃ Overusing time threshold AND Overuse counter ˃1 
 19 /* check whether if the current offset estimate larger than the previous one 
 20 or not */ 
 21 IF current offset ˃ previous offset THEN 22 time of overusing = 0 //reset the counter 
 23 //reset the counter 
 24 Overuse counter = 0 
 25 Overuse detector state = Overuse 26 END IF 
 27 END IF 28 ELSE IF T < γ 
 29 //reset the counter 
 30 time of overusing = 0 
 31 Overuse detector state = Underuse 
 32 ELSE 33 time of overusing = 0 
 34 //reset the counter 
 35 Overuse counter = 0 
 36 Overuse detector state = Normal 37 END IF Algorithm-2: Rate control region algorithm 1 IF Control-Region = MaxUnKnown THEN 2 /*γ is threshold, γe is default threshold; i. e. chrome threshold 5g hi ms ∗/